\subsection{Implementation}

Stubs for web services have been created with the help of AXIS2. While
these stubs offer a simple access to the web services, the objects that
encode requests and responses are rather generic and contain
information that is not directly used in our application.
To simplify things, we have created objects that represent the
main logical entities in this application (located in the
\emph{ch.ethz.eai.data} package):
\begin{itemize}
  \item \emph{Location} -- encodes a physical location identified by a
    pair of coordinates, and a postal address. We used the web services
    to resolve the missing part of the location information.
  \item \emph{PointOfInterest} -- this represents a venue, that has a
    location, a name, and a type. The location is encoded using the
    object presented above, while the type is just an identifier of
    what sort of venue it is (e.g. golf, bar, night-club).
  \item \emph{WeatherStatus} -- the status of weather at a given
    location is represented using this object. It has a location and
    an identifier for the weather type, and a timestamp that records
    when the status has been created. This is important because old
    statuses have to be discarded eventually from the system (in order
    to provide users only with up-to-date information).
\end{itemize}

Using the above mentioned objects we have created facades in front of
the web service stubs, that would accept and return our data objects
instead of generic response objects. These facades can be found in the
\emph{ch.ethz.eai.facade} package.

Weather statuses are stored in the \emph{StatusStore} which provides a
convenient query interface. One can ask for the weather type the
majority reported in a radius around a pair of
coordinates. The radius has been added as a parameter, because the
granularity of reporting will not be the same, for instance in New York City and the
country-side, and eventually, the radius could
be reduced for areas where dense weather information is available, and
enlarged where user updates are expected to be rather sparse.
Internally the status-store keeps a collection of
\emph{WeatherStatus}es, from which the expired (those which are older
than a threshold, e.g. 30 minutes) statuses are discarded upon
traversal at query-time. 

% After the stubs for the web services have been created using AXIS2, we added
% wrappers around them to provide a simpler interface for
% access (see). 
% AXIS would usually create objects out of the WSDL which are quite
% contrived to access, and therefore 

% Instead of passing strings to the methods, we
% created some simplified representations of notions
% appearing in the SOAP interfaces (see ). For instance, The reverse geocoding
% service returns an answer which is rather complex to access, but its
% information can be stored in a \emph{Location} object, that has both
% coordinates and an address-based location. Based on \emph{Location} we
% also created a \emph{PointOfInterest} which has in addition to the
% former a venue name.

% To describe the weather we used a simple object \emph{WeatherStatus}
% which along with the weather stores the place and the time from when
% it was reported. These statuses are then stored in the
% \emph{StatusStore}, which can be queried for the weather in a radius
% around a coordinate. The date included with the statuses is used to
% discard old messages (we used a threshold of half-hour).

\subsection{Testing and Challenges}

Testing was carried out using JUnit test cases (see
\emph{ch.ethz.eai.test}) which ensure, that by using the facades, no
information is lost or altered when communicating with the outside web
services. An other test class was used to check whether the status
store was aggregating the user updates correctly.

One of the biggest challenges in implementing the service facades in a
reliable manner was that sometimes the services (especially the
reverse geocode) would return non-deterministic data. That is, in some
cases it would correct Zurich to Z\"{u}rich, and other times
not. Therefore some ``rules'' of information preservation were added
to the facade.

It also has to be mentioned that one of the the weather service's big
drawback is that it does not return an ID
for the weather kind, but it returns instead a string describing the
conditions. 
In order to translate this into our internal representation we decided
to look for some predefined keywords (like ``overcast'') in the
response. While this is a workaround, we considered this design
decision acceptable for the sake of this project.

